Mobile terminals, such as mobile telephones, Personal Digital Assistants (PDAs) and the like have an ever-increasing number of functionalities. Where once a mobile terminal was just for transmitting and receiving communications between two entities, now such terminals have innumerable additional functionalities, which are enabled by so-called “Widgets”.
In a computing context, a Widget is a single function application that performs a specific task or function. A Widget could also be described as an executable file or applet. Most typically Widgets download data from an external network source, and use that data to display information to the user. The displayed information may invite the user to act in a number of ways. For instance, the user may use graphical components, such as buttons, dialog boxes, pop-up windows, pull-down menus, icons, scroll bars, resizable window edges, progress indicators, selection boxes, windows, tear-off menus, menu bars, toggle switches and/or forms to interact with the Widget.
It is to be appreciated that the term “Widget” can also be used to refer to the graphic component rather than its controlling application or to the combination of both.
Many, but not all, Widgets leverage web technologies to perform a specific task or function and typically display something to the user. An example of one such application is a stock-market Widget that displays the share price of certain stocks, typically stocks pre-designated by the user. A further example is a Widget that is configured to display weather details for one or more pre-designated locations.
Today, mobile terminals typically have multiple Widgets installed, any or all of which can be implemented at any one time. While this provides the mobile terminal with enhanced utility, regular and/or concurrent use of many of the Widgets unfortunately leads to a greater drain on battery resources. The lifetime of a mobile terminal's battery is an extremely important aspect, as users find it undesirable to have to be recharging their terminal's battery with any great regularity, or even worse, having the terminal shut down unexpectedly due to a lack of battery power.
Further, where the Widget is implemented on a mobile terminal, since a cellular network is involved, a Packet Data Protocol (PDP) context additionally needs to be created, in order to send and receive packet switched data via the General Packet Radio Services (GPRS) Core Network. Therefore, before the Widget Engine 11 transmits the data request to the Internet address, via the cellular network, a PDP context needs to be set up. The PDP context is a data structure typically stored on both the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN) associated the Radio Network Controller (RNC) serving the terminal in the cellular network. The PDP context contains the terminal's active session information. For instance, when a mobile terminal wants to use GPRS, it must first attach and then activate a PDP context. This allocates a PDP context data structure in the SGSN that the subscriber is currently visiting and the GGSN serving the terminal's access point. The PDP context is essentially used by the cellular network to know where to route data intended for the mobile terminal.
In order to send and receive packet switched data the Widget Engine would invoke an HTTP-related API which in turn would trigger the afore-mentioned PDP context set-up. The API would convey the request to the web address 13 via the HTTP Stack 12, which conforms the request according to the Protocol requirements, so that it can be transmitted across the Internet.
Ideally the PDP context is dismantled once the required data has been transmitted. However, it is to be appreciated that in establishing and dismantling the PDP context, more data is required to be transmitted than would be used to transmit the actual content to the terminal. This approach is therefore wasteful and not ideal.
This problem is heightened when multiple widgets are operating at any one time, since the PDP contexts may need to be regularly established and dismantled, using up a lot of network resources.
This problem could be addressed by not dismantling the PDP contexts, and relying on the network to “time out” each PDP context after a particular period of inactivity. This solution is not ideal, however, since the MSC/SGSN can only support a particular number of PDP contexts simultaneously and this approach provides no guarantees that a MSC/SGSN will not be supporting PDP contexts of terminals no longer requiring internet access.
In this regard, it should also be noted that a cellular network is set up with the expectation that not all terminals will have a PDP context established simultaneously.